Many existing computing systems in an organization rely on centralized identity management systems. For example, user name and password information for a user is managed centrally within the organization. In contrast, some existing computing systems use federated identities. In a federated identity platform, an organization relies on an external trust provider (e.g., an identity provider) to manage authentication. Multiple organizations may participate in the federated identity platform. In such systems, documents describing the organizations participating in the federation are often publicly available (e.g., over a network). In this manner, organizations or other participants in the federation can learn about how to interact with other participants by accessing these documents. The documents include, for example, metadata documents conforming to the Security Assertion Markup Language (SAML) specification, and eXtensible Resource Descriptor Sequence (XRDS) documents conforming to the OpenID brand software.
In a cloud computing environment, multiple tenants share hardware and software resources to reduce costs and complexity while increasing performance and efficiency. For those multi-tenant public cloud service providers that participate in a federated identity system, the cloud service providers expose the metadata documents for each of the tenants of the cloud service provider. For example, an application executing by the cloud service provider may expose the metadata documents, via a uniform resource location (URL), to enable identity providers in the federation to poll the URL and update their configuration when the metadata documents change. A document URL corresponding to an organization that is not a tenant of the cloud service provider results in an error response (e.g., “file not found”). To maintain the privacy of the tenants, the existing systems are undesirable because they allow a third party to probe document URLs to test whether an organization has an account with the cloud service provider.
Some cloud service providers that participate in federated identity platforms require additional authentication to the cloud service provider before accessing the metadata documents. This requires the cloud service provider to maintain an authentication mechanism separate from, and in addition to, the authentication provided by the identity provider, thereby forcing a system administrator to manage multiple systems with authentication and identity policy spread across multiple software stacks. As a central goal of identity federation is to have authentication managed by the identity provider exclusively, the existing solutions for maintaining the privacy of tenants in such cloud service environments are inadequate.